-
Notifications
You must be signed in to change notification settings - Fork 9
feat: Implement per-device polling and on-change publishing #28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Implement per-device polling and on-change publishing #28
Conversation
…the global 'pollinterval' from modbus.toml
…ange in data, it won't publish the data
Robot Results
Passed Tests
|
|
@mucahitkls Thanks for the PR and the very thorough description explaining the new behaviour. Any chance that you could also add a tests, either unit tests (python) or system units (Robot Framework). If you need assistance, then we can help out. |
|
@mucahitkls Can you also run the formatting and linting using the following commands: (though I'm pretty sure the formatter (black) after looking at the lint errors) just format
just lint |
The class was using a class-level variable for its cache, which is intended to store the last-published values for the on-change publishing feature. This created a bug where a single cache dictionary was shared across all instances. When polling multiple devices, the mapper for one device would read or overwrite the cached values of another. This interference caused the on-change logic to behave unpredictably, particularly failing to publish a value on the first poll because it incorrectly found a stale value from a different device's polling cycle. This issue was discovered when unit tests for the on-change feature consistently failed, as the shared state persisted between test cases. The fix moves the cache initialization into the method, converting it from a shared class variable to a private instance variable. This ensures that each mapper instance—and therefore each Modbus device being polled—has its own isolated cache. This change corrects the on-change publishing behavior to be reliable and robust on a per-device basis and allows unit tests to pass successfully.
Adds unit test suites for the ModbusMapper and ModbusPoll classes to validate the new on-change and per-device polling features.
These tests verify two key areas:
- **On-Change Publishing ():**
This suite confirms that the correctly publishes MQTT messages only when a register's value has changed. It covers scenarios for integers, floats, initial polls, and the fallback behavior.
- **Per-Device Polling ():**
This suite uses mocking to ensure the scheduler uses the device-specific when available and correctly falls back to the global when it is not.
These tests provide confidence in the correctness of the new features and protect against future regressions.
|
Hello, Unit tests have been added to the project to validate the new efficiency features: per-device polling intervals and on-change publishing. During the development of these tests, a possible bug was discovered in the It is resolved by converting the cache to an instance variable within the mapper's |
|
@mucahitkls Looks like the macOS preview file (.DS_Store) made it into the PR before you added the gitignore rule. |
|
hello, sorry for inconvenience, now it should be fine |
reubenmiller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mucahitkls Looks good and thanks for taking the time to also add unit tests
|
@mucahitkls Sorry just spotted a few minor things (more of a consistency thing). https://github.com/thin-edge/modbus-plugin/pull/28/files#r2207606778 |
…perties are added in devices.toml with commented out
|
please let me know if it need to be updated |
Pull Request Description:
This pull request introduces two key efficiency enhancements to the Modbus plugin, designed to reduce unnecessary data traffic and allow for more flexible polling strategies.These changes enable users to prioritize high-frequency data from critical devices while minimizing network and cloud resource usage for static or infrequently changing data points.
Motivation
In many industrial environments, it's necessary to monitor certain devices (like critical sensors) at a high frequency (e.g., every second), while other devices only require infrequent updates. Similarly, some registers, such as status flags, only need to be reported when their value changes. This implementation addresses that need by providing more granular control over data polling and publishing.
Features Implemented
1. Per-Device Polling Interval
This feature allows a custom polling interval to be set for each individual Modbus device, overriding the global default.
poll_intervalkey within a device's configuration in thedevices.tomlfile. If this key is present, its value is used for that specific device. If it is absent, the plugin falls back to the globalpollintervaldefined inmodbus.toml, ensuring full backward compatibility.poll_interval = <seconds>to a[[device]]table indevices.toml.2. On-Change Publishing
This feature prevents the plugin from publishing data for a register if its value has not changed since the last poll.
on_change = true, the plugin caches the last published value. A new MQTT message is only published if the newly polled value is different from the cached one, or on the very first poll for that register. If theon_changekey is false or absent, the default behavior of publishing after every poll is maintained.on_change = trueto a[[device.registers]]table indevices.toml.Example Configurations
Test
modbus.toml:Test
devices.tomlwith new updates: